REMARKS 



Claims 1-10, 12-13, 15-24, 26-27, 29-39, 41-42, 44-54, 56-57, and 59-64 are 
pending in this application. By this Response, claims 1,16, 26, 30, and 45 are amended 
to clarify the definition of a transaction, which is a sequence of a plurality of transaction 
steps which together are treated as a single unit. Support for the inclusion of this 
definition may be found in the present specification at least in Figures 3A, 3B, 4A, and 
4B and the corresponding description which describes the columns of these figures as 
representing the individual transaction steps of a transaction implemented by a script as 
well as describe 3 1 3 and 4 1 3 as representing whether a transaction as a whole is 
complete, i.e. all of the transaction steps are completed (see paragraph [0047] of the 
corresponding publication 2003/0145080, for example). Furthermore, Applicants are 
providing attached hereto a definition obtained from the website searchcio.techtarget.com 
referencing the definition from www.whatis.com which shows the general knowledge of 
one of ordinary skill in the art with regard to the definition of the term "transaction." 

Independent claims 1,16, 26, 30, and 45 are further amended to define the 
transaction steps as representing a user of a client computing device's interaction with one 
or more applications of a server computing device. This is further supported by Figures 
3A-4B and corresponding description in the specification. 

Claims 30 and 45 are further amended to remove "means-plus-function" language 
from the claims to address the 35 U.S.C. § 112, second paragraph rejection first raised in 
the Examiner's Answer mailed May 27, 2010. Dependent claims 3 1-34, 37-39, 41-42, 
44, 46-54, 56-57, 59 and 64 are amended to be consistent with the amendments to claims 
30 and 45 and to further remove any means-plus-function recitations in these claims. 
Support for the amendments to these claims to replace means-plus-function language 
with specific elements may be found at least in Figure 2 and its corresponding 
description, and with regard to the computer program product elements, paragraph [0094] 
of the corresponding publication 2003/0145080. No new matter has been added by any 
of the above amendments to the specification or claims. Reconsideration of the claims in 
view of the above amendments and the following remarks is respectfijUy requested. 
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I. Request to Reopen Prosecution 



In accordance with the options presented to Applicants on pages 1 5-16 of the 
Examiner's Answer, Applicants hereby request that prosecution of the present application 
be reopened in accordance with 37 CFR 4 1 .39(b)( 1 ) since a new grounds of rejection 
was introduced in the Examiner's Answer. Since the present amendment is relevant to 
the new grounds of rejection, Applicants respectfiilly request entry and consideration of 
this Amendment in accordance with 37 CFR 41 .39(b)(1). 

II. Request to Make Special and Request for Examiner Telephone Interview 

Applicants hereby request that the present application be considered "Special" 
and that the Examiner's supervisor personally intervene in the prosecution of this 
application in an effort to terminate prosecution with allowance of the application in 
accordance with MPEP § 707.02 which reads: 

The supervisory patent examiners should impress their assistants with the 
fact that the shortest path to the final disposition of an application is by 
finding the best references on the first search and carefully applying them. 

The supervisory patent examiners are expected to personally check on 
the pendency of every application which is up for the third or 
subsequent Office action with a view to finally concluding its 
prosecution. 

Any application that has been pending five years should be carefully 
studied by the supervisory patent examiner and every effort >should be< 
made to terminate its prosecution. In order to accomplish this result, the 
application is to be considered "special" by the examiner. 

(emphasis added) 

The present application has been pending for over five years. Accordingly, Applicants 
respectfully request that the Supervisory Examiner review the prosecution history of this 
application, the amendments and remarks made throughout the prosecution of this 
application and included herein, and either allow the application or contact Applicant's 
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undersigned representative and provide suggested claim amendments that will place this 
application in condition for allowance. 

It is believed that the issues currently pending in this application may be resolved 
by way of an Examiner Interview with the Examiner and his supervisor. Accordingly, 
Applicants respectfully request that the Examiner and his supervisor schedule a telephone 
interview with Applicants' undersigned representative to discuss a resolution of the 
application towards a final disposition of the application. Applicants have set forth 
amendments above which Applicants believe to place the application in condition for 
allowance in view of the Examiner's rejections and arguments set forth in the Examiner's 
Answer. However, Applicants are willing to consider other suggestions by the Examiner 
that would place the case in condition for allowance in the Examiner's view. Thus, 
Applicants respectfully request that the Examiner and his supervisor provide Applicants 
with an opportunity to discuss the merits of this case. 

111. Response to Examiner's Arguments in Examiner's Answer 

Applicants arguments presented in the Appeal Brief filed August 10, 2006 and the 
Amended Appeal Brief filed October 27, 2006 are considered to still apply to the current 
state of the claims and are thus, set forth hereafter. In this section of this Amendment, 
Applicants will address the specific arguments presented by the Examiner on pages 11-15 
of the Examiner's Answer. 

In response to Applicants' argument with regard to the terms transaction and 
transaction step, the Examiner alleges that transactions can be a set of commeuids or each 
step c£ui be a unit with related events. Applicjints respectfiilly disagree with this 
interpretation. 

The present specifically clearly defines a transaction as having a plurality of 
transaction steps that together constitute a single unit, i.e. the transaction. This is 
recognized by the Examiner in the first paragraph on page 12 of the Examiner's Answer 
where the Examiner correctly states that each transaction consists of a plurality of steps. 
Moreover, as shown in the definition of the term "transaction" set forth by the 
www.whatis.com website (see attached), those of ordinary skill in the art regard a 
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transaction as a sequence of information exchange and related work that is treated as a 
unit for the purposes of satisfying a request. Thus, both the present application and the 
general knowledge of those of ordinary skill in the art both support the definition of the 
term "transaction" to be a sequence of transaction steps. In order to further emphasize 
this definition being applicable to the transaction recited in the claims, the definition has 
been added to the claims by reciting that the transaction is a sequence of the plurality of 
transaction steps which together are treated as a single unit. 

The Examiner goes on to allege that any part of the "hierarchy" described in 
Chandra may be considered a "transaction." Specifically, the Examiner alleges that 
because Chandra's test protocols can include a plurality of test scripts (column 7, lines 
41-43) and that a script can be broken down into steps and sub-steps, that somehow this 
teaches the specific transactions, transaction steps, and reports having individual 
transaction step entries having performance data for the particular transaction step, To 
the contrary, nowhere in Chandra is there any teaching or technical rationale to consider 
anything in the Chandra test protocols to be transactions or steps of a transaction, as it has 
been defined by Applicants, the definition now being integrated into the claims by this 
Amendment. In fact, the Examiner agrees that Chandra does not teach a transaction as it 
has been defined by Applicants (see Examiner's Answer, page 1 3, where it is stated 
"Chandra's definition of transaction does not match the application's definition of 
treinsaction"). 

Moreover, even if what the Examiner alleges were true and the scripts in Chandra 
could be interpreted to be a single transaction comprised of a plurality of transaction 
steps, arguendo, the reporting done by Chandra is done on a connection basis. That is, 
Chandra specifically teaches that the timing measurements are with regard to 
performance measurements of throughput and transaction rate, i.e. numbers of 
transactions handled per unit of time over a particular cormection (column 8, lines 48-57). 
Chandra does not gather performance information for individual steps of a script and 
provide an entry in reports for each step in the script. To the contrary, in Chandra, the 
scripts simply operate to collect throughput and transaction rate measurements for a 
connection and then report this information back to a console node that generates 
statistics. Nowhere in Chandra is there any ability to collect individual performance data 
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from a plurality of probes for each transaction step of a transaction executed by a script 
such that a report may be generated that comprises a plurality of transaction step entries, 
one entry for each transaction step of a script. Chandra is only concerned with the 
performance measurements of the connection, not the transaction. 

Rather than actually finding the specific features recited in the claims, the 
Examiner is engaged in an exercise of making tenuous interpretations of hierarchies of a 
script including steps and sub-steps and alleging that each of these steps and sub-steps 
could be part of a transaction and then one could gather data for each of these transaction 
steps. However, there is no teaching or suggestion In Chandra to do such. The only 
teachings or suggestions are necessarily found in Applicants' own disclosure. To the 
contrary, the Examiner is trying to make the reference fit the mold of the present claims 
rather than determining if the claimed features are actually taught by the reference. This 
is clear in that the Examiner is having to explain a convoluted interpretation of 
hierarchies of functionality and scripts and functions within scripts, etc., and trying to 
equate these to features found in the claims rather than simply finding a reference that 
teaches generating a report where the report has individual entries for individual 
transaction steps of a transaction and their corresponding performance data. 

This desire to disregard the actual teachings of Chandra and instead force Chandra 
to fit within the mold of the present claims is further evident in statements by the 
Examiner with regard to not using the definitions of the terms set forth in the application 
(Examiner's Answer, page 12, second paragraph), looking at the hierarchical association 
"regardless of how the term of transaction is used" in the Chandra reference (Examiner's 
Answer, page 12, bottom of the page), and the like. The reality is that Chandra teaches 
that the performance data collected by Chandra is with regard to throughput and 
transaction rate, i.e. on the whole transaction level with regard to the number of 
transactions processed per unit time. This is because the measurements made by Chandra 
are concerned with the performance of the connection, not the performance of the 
transaction or individual steps of the transaction. 

The Examiner alleges that "one of ordinary skill in the art cannot simply zero in 
on the term transaction and force upon it the application's definition." This is absolutely 
contrary to all doctrines and tenets of patent law. It has long been held that Applicants 
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are permitted to be their own lexicographer and that the application's description is 
intended to be a dictionary for the terms used in the claims. Thus, the reality is that the 
claims must be read in light of the present application's description and that the terms in 
the claims must be given definitions consistent with the description in the application. 
Furthermore, terms not specifically defined in the specification may be given a definition 
corresponding to that known to those of ordinary skill in the art. Moreover, Applicants 
may limit the definition of terms through prosecution history estoppel by specifically 
setting forth the definition of terms in Applicants' arguments which will then be used to 
interpret the terms set forth in the claims. 

All of this combines to essentially make the point that Applicants may set forth 
the definition of the terms in the claims and the Examiner must interpret the claims in 
light of such definitions. Applicants have done so here both by showing the consistency 
of the definition of the term "transaction" known to those of ordinary skill in the art and 
the usage of that term throughout the present specification. Moreover, Applicants have 
set forth the definition of the term "transaction" both by Applicants' arguments and by 
explicitly including the definition in the claims themselves. Thus, the Examiner must 
interpret the claims in light of Applicants' definition of the term "transaction" and cannot 
simply dismiss this definition because it would cause the Examiner's found reference to 
not be applicable to the present claims. 

The Examiner goes on to allege that Chandra teaches a variety of reports on 
connections and sub-steps of connections and thus, the features of the reports having 
individual entries of transaction steps of a transaction are allegedly taught by Chandra 
(see Examiner's Answer, page 14). Applicants respectfiiUy disagree. While Chandra 
may teach different types of reports, none of these reports include individual transaction 
step entries with performance data for the individual transaction steps of a script. To the 
contrary, the Examiner himself says that the reports are periodic reports "by various 
connections, script, and transaction count." None of these are reports having individual 
transaction step entries for each transaction step in a script and their corresponding 
performance data. To the contrary, these are all connection level reports because 
Chandra is concerned with the performance of a connection as a whole, not the 
performance of a transaction. One cannot determine the performance data for individual 
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transaction steps within a transaction from the reports in Chandra because all that 
Chandra reports is the throughput and transaction rates of connections. 

Lastly, the Examiner alleges that the layout of data output is not functional. 
While the layout may or may not be functional, the operation for laying out the data in 
the particular format specified is functional. In other words, the claims specifying the 
format of the reports further define the manner by which the reports are generated, in 
addition to providing fiinctionality to the user as previously argued. Thus, these claims 
do further define the functionality of the claimed invention by specifying the manner by 
which the reports are generated. Thus, these features should be given weight during 
examination. 

IV. Rejection under 35 U.S.C. 6 112. Second Paragraph fNew Grounds of 
Rejection) 

The Examiner's Answer sets forth a new grounds of rejection of claims 30-59 
under 35 U.S.C. § 1 12, second paragraph. This rejection is respectfijUy traversed. 

By this Response, claims 30-59 are amended to remove the "means-plus- 
function" language that is the basis for the Examiner's holding of these claims to be 
allegedly indefinite. As a result, this rejection is rendered moot. Accordingly, 
Applicants respectfijlly request withdrawal of the rejection of claims 30-59 under 35 
U.S.C. § 112, second paragraph. 

V. Rejection under 35 U.S.C. S 103fa) based on Hershev and Chandra 

The Final Office Action rejects claims 1, 3-7, 9, 12, 16, 17, 19-21, 23, 26, 29, 30, 
32-36, 38, 41, 45, 47-51, 53, and 56 under 35 U.S.C. § 103(a) as being allegedly 
unpatentable over Hershey et al. (U.S. Patent No. 5,793,753) in view of Chandra et al. 
(U.S. Patent No. 6,397,359). This rejection is respectfully traversed. 

Claim 1, which is representative of the other rejected independent claims 30 and 
45 with regard to similarly recited subject matter, reads as follows: 
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1 . A method for communicating performance information, said 
method comprising: 

configuring a plurality of probes to execute a script for performing 
a transaction between a client computing device and a server computing 
device, wherein the script comprises a plurality of transaction steps for 
performing the transaction, and wherein the transaction is a sequence of 
the plurality of transaction steps, representing an interaction between a 
user of a client computing device and one or more applications running 
on the server computing device, which together are treated as a single 
unit; 

collecting data from the plurality of probes, including at least one 
local probe and at least one remote probe, wherein the collected data is 
data representative of a performance of the transaction steps of the 
script executed by the plurality of probes; and 

reporting said data, wherein reporting said data comprises 
generating a report that comprises a plurality of transaction step entries, 
one entry for each transaction step of the script, having associated 
performance data collected from one or more of the at least one local 
probe or the at least one remote probe, (emphasis added) 

Neither Hershey nor Chandra, either alone or in combination, teach or suggest the 
features of claim 1 emphasized above. Hershey is directed to a system for management of 
a telecommunications network. Hershey teaches the use of a programmable probe that is 
connected to a network device for monitoring data transfer activity on the network and 
collecting selected data relating to one or more relevant functions. The probe may be 
programmed to effect collection of data relative to a selected function parameter. The 
collected function parameter data may be received from the probe and stored. A data 
output device may be provided for outputting the parameter data to a user. Furthermore, 
Hershey teaches comparing the parameter data to a reference value and providing an 
indication when the parameter data deviates from the reference value by more than a 
preselected threshold (column 2, lines 11-55). 

Hershey, however, does not teach programming a probe with a script for 
performing a transaction between a client device and a server device, wherein the script 
includes a plurality of transaction steps. To the contrary, Hershey only teaches being able 
to program the probe to collect data for particular functions. Hershey does not provide any 
script for performing a transaction between a client device and a server that includes a 
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plurality of transaction steps. Thus, Hershey also does not teach collecting data that is 
representative of a performance of the transaction steps of the script. 

Moreover, Hershey does not teach reporting the collected data, wherein reporting 
the collected data comprises generating a report that comprises a plurality of transaction 
step entries, one entry for each transaction step of the script, having associated 
performance data collected from one or more of the at least one local probe or the at least 
one remote probe. While Hershey states that parameter data may be output to the user 
via an output device, Hershey provides no details as to how such an output is provided. 
Specifically, Hershey does not teach that such an output comprises a report having a 
plurality of transaction step entries, one entry for each transaction step of a script that is 
used to program the probes, and associated performance data collected from the probes. 
The Final Office Action admits that Hershey does not teach these features (see Final 
Office Action, page 3, paragraph 9). However, the Final Office Action alleges that these 
features are taught by Chandra. Applicants respectfully disagree. 

Chandra is directed to a mechanism for scheduled measurement of connections 
between end nodes. The end nodes are provided with test protocols that have test scripts. 
These test scripts are used to measure the performance of the connection between the end 
nodes without requiring any involvement of application software which may or may not 
be present on the end nodes (column 3, lines 16-50). The system of Chandra may make 
measurements of the connection performance at scheduled times and may store this 
information until a request for a report is received, or an automatic scheduled report is 
performed. The reports are provided to a console node which generates statistics for the 
connection based on the measured performance. 

Chandra is not concerned with measuring the performance of transactional steps 
of a script but rather merely the performance of the connection as a whole. Thus, 
Chandra does not teach or even suggest to measure the performance of individual 
transactional steps of a script and provide a report having entries for each of the 
individual transactional steps. 

The only mention of "transactions" in Chandra is in the Background of the 
Invention section where Chandra discusses a known system management tool (see 
column 1, lines 54-66). As discussed in this Background section of Chandra, one known 
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system management tool involves actively emulating application transactions. Agents at 
the end user locations monitor actual sample application transactions to measure 
performance of the application operating over the network environment. While Chandra 
teaches that such system management tools exist, Chandra takes an opposite approach by 
concerning itself with only the measurements of the connections between end nodes 
without requiring any involvement of application software which may or may not be 
present on the end nodes (see column 3, lines 20-23, "...without requiring any 
involvement of application software...", and column 3, lines 39-41, "...without regard to 
the end user application programs available at particular endpoints. . ."). While the 
Background in Chandra mentions using synthetic transactions to monitor performance of 
applications, the monitoring is done on a transaction level. There is no mention in 
Chandra of monitoring the performance of individual steps in the transactions or 
providing a report having entries for each transaction step of a transaction in a script. 

Moreover, other than the above mentioned portion of the Background section in 
Chandra, the only other mention of transactions in Chandra is that the performance 
measure may include transaction rates. Thus, yet again, the performance measure is at a 
transaction level rather than at a level corresponding to individual transaction steps of a 
transaction. Hence, even if Chandra does perform measurements of connection 
performance with regard to transactions, the measurements are not done with regard to 
individual transaction steps such that a report having entries for each transaction step of a 
transaction in a script is provided. Thus, contrary to the allegations raised by the Final 
Office Action, Chandra actually does not teach or even suggest to measure performance 
of transactional steps but instead to only measure the performance of a connection 
between end nodes, which at most may be performed on a transaction basis, not 
individual transaction steps. 

The Final Office Action alleges that Chandra teaches the collection of data for 
reporting at column 8, lines 22-35, column 13, lines 10-1 1, column 16, line 20 to column 
18, line 35, and column 3, lines 45-47. Column 8, lines 22-35 of Chandra teaches that the 
endpoint node pairs generate timing records and calculate performance test results from 
these timing records and provide these performance test results to a console node. The 
console node may then analyze the performance test results. Column 1 3, lines 10-1 1 of 
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Chandra teaches that the results may be stored until an appropriate time for a batch or 
event driven reporting of results to the control node. 

Column 16, line 20 to column 18, line 35 provides a number of tables describing 
connection analysis results and periodic report results. It is important to note that 
nowhere in these tables is there anything regarding providing a report that has entries for 
each transaction step of a transaction in a script. To the contrary, the only mention of 
transactions in these tables is the transaction count which is a count of a number of 
transactions. There are no entries in any of the "results" tables of Chandra regarding 
individual transaction steps of a transaction in a script. 

Column 3, lines 45-47 of Chandra teaches that network test results may 
encompass an end-to-end view and may further break network performance analysis 
down into its components, such as client, server, application, and network time, to 
potentially quickly and accurately isolate problems. While this section talks about 
breaking down results into various parts of the network, i.e. client, server, application, 
etc., there is no teaching or even suggestion in this portion of Chandra regarding 
providing a report having entries for each of the transaction steps of a transaction in a 
script. 

Thus, neither Hershey nor Chandra, either alone or in combination, teach or 
suggest that collected data is data representative of a performance of transaction steps of 
a transaction in a script executed by a plurality of probes. Moreover, neither Hershey nor 
Chandra, either alone or in combination, teach or suggest reporting the data, wherein by 
generating a report that comprises a plurality of trjinsaction step entries, one entry for 
each transaction step of the script, having associated performance data collected from one 
or more of at least one local probe or at least one remote probe. Therefore, even if 
Hershey were combinable with Chandra, and one were somehow motivated to attempt 
such a combination, arguendo, the result of the combination still would not result in these 
features of independent claims 1, 30 and 45 being taught or suggested. 

Regarding independent claims 1 6 and 26, these claims recite similar features to 
that emphasized above. For example, claim 16 recites; 
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16. A method for communicating performance information, said 
method comprising: 

configuring at least one probe to execute a script for performing a 
transaction between a client computing device and a server computing 
device, wherein the script comprises a plurality of transaction steps for 
performing the transaction, and wherein the transaction is a sequence of 
the plurality of transaction steps, representing an interaction between a 
user of a client computing device and one or more applications running 
on the server computing device, which together are treated as a single 
unit, 

receiving data from the at least one probe, wherein the collected 
data is data representative of a performance of the transaction steps of 
the script executed by the at least one probe; 

comparing said data with at least one threshold value derived from 
a service level agreement; and 

reporting results of said comparing, wherein the reported results 
comprise a plurality of transaction step entries, one entry for each 
transaction step of the script, having associated performance data 
collected from the at least one probe. 
(emphasis added) 

Claim 26 recites similar features. Thus, claims 16 and 26 are distinguished over the 
Hershey and Chandra references for similar reasons as set forth above with regard to 
independent claims 1, 30, and 45. 

At least by virtue of their dependency on claims 1,16, 26, 30, and 45, 
respectively, neither Hershey nor Chandra, either alone or in combination, teach or 
suggest the features of dependent claims 3-7, 9, 12, 17, 19-21, 23, 29, 32-36, 38, 41, 47- 
51, 53, and 56. 

In response to the above arguments, the Examiner, in the Advisory Office Action 
mailed May 26, 2006 states: 



The examiner has determined that the steps within a given test 
script, i.e. a connection within a set of connections, is fiuictionally 
equivalent to a transaction as currently defined by the instant applications, 
as fxirther indicated by the transaction count associated with the results of 
the test script as broken down into test components, i.e. per connection 
analysis. From this, it is clear that Chandra teaches the development and 
execution of a script composed of multiple steps, each step thus 
comprising a transaction, and further that Chandra teaches a breakdown of 
information by test script portion/transaction result (i.e. timing record per 
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connection analysis) to the stored and/or reported, as shown in the Final 
Office Action. 

Essentially the Examiner's response is that because Chandra teaches a test script, 
transaction counts, and the ability to break down results into components of a network, 
that this obviates the claimed invention. Applicants respectfully submit that the 
Examiner is reading in limitations of the claimed invention into the teachings of Chandra 
having first had benefit of Applicants' own disclosure. 

Nowhere in Chandra is there any teaching to break down performance 
measurements into individual transaction steps of a script. All that Chandra teaches is 
that network test results may encompass an end-to-end view and may further break 
network performance analysis down Into its components, such as client, server, 
application, and network time, to potentially quickly and accurately isolate problems in 
the network (see column 3, lines 44-47). Thus, while performance measurements may be 
broken dovm into individual network components, there is no teaching or suggestion to 
correlate such performance measurements to individual transaction steps of a script or to 
generate a report having entries for individual transaction steps. From the performance 
measurements of Chandra, all that can be determined is where latencies in a connection 
between two endpoints may be present and thus, a potential problem. It is not possible to 
determine in Chandra what the performance of individual transaction steps of a script is, 
let alone generate a report having individual transaction step entries with corresponding 
performance data collected from one or more of the at least one local probe or the at least 
one remote probe, as recited in claims 1, 30, and 45. 

VI. Reiection under 35 U.S.C. 6 103fa) based on Hershev. Chandra and 
Schwaller 

The Final Office Action rejects claims 2, 8, 10, 13, 15, 18, 22, 24, 27, 31, 37, 39, 
42, 44, 46, 52, 54, 57, and 59 under 35 U.S.C. § 103(a) as being allegedly unpatentable 
over Hershey and Chandra, and further in view of Schwaller et al. (U.S. Patent No. 
6,901,442). This rejection is respectfully traversed. 
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Claims 2, 8, 10, 13, 15, 18, 22, 24, 27, 31, 37, 39, 42, 44, 46, 52, 54, 57, and 59 
are dependent claims that are dependent upon respective ones of independent claims 1 , 30 
and 45. Thus, at least by virtue of their dependency, these claims are not taught or 
suggested by the alleged combination of Hershey and Chandra for the reasons set forth 
above in section 1. Moreover, Schwaller does not provide for the deficiencies noted 
above with regard to Hershey and Chandra. 

Schwaller is directed to a mecheinism for filtering of network performance data. 
Nowhere in Schwaller is there any teaching or suggestion to program a probe with a 
script that comprises a plurality of transaction steps for performing a treuisaction between 
a client device and a server device. Schwaller merely states that the data may be 
collected in response to active testing of the network or passive data collection (column 
7, lines 55-65). Schwaller does not provide any teaching or even suggestion regarding a 
script such as that recited in independent claims 1, 30, and 45. 

Furthermore, Schwaller does not teach or suggest a report such as that recited in 
claims 1, 30, and 45. Schwaller does show various outputs in Figures 9A-13. However, 
in none of these outputs is there any report such as that recited in claims 1, 30, and 45. 
That is, none of the outputs of Schwaller show a report that comprises a plurality of 
transaction step entries, one entry for each transaction step of a script, having associated 
performance data collected from one or more of the at least one local probe or the at least 
one remote probe. To the contrary, the outputs generated by Schwaller may provide 
performance data for a plurality of applications (see Figure 9A of Schwaller), but there is 
no indication of any transaction steps of a script that is used to program a probe in any of 
the outputs of Schwaller. 

In fact, there is no ability in Schwaller to match any of the data output by 
Schwaller to transaction steps of a script used to program a probe. Schwaller does 
provide an output of a distribution of response times for transactions (see Figure lO.C. 1), 
however, there is no indication of the individual transaction steps for the transactions or 
the corresponding performance data for such transaction steps in any of the outputs 
provided by Schwaller, similar to Chandra discussed above. Thus, Schwaller, like 
Hershey and Chandra, does not teach or suggest the features of independent claims 1, 30, 
and 45. Since none of these references teach or suggest these features, any alleged 
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combination of the references, even if such a combination were possible and one of 
ordinary skill in the art were somehow motivated to make such a combination, would not 
result in these features being taught or suggested. 

In view of the above. Applicants respectfully submit that neither Hershey, 
Chandra, nor Schwaller, either alone or in combination, teach or suggest the features of 
independent claims I, 30, and 45. At least by virtue of their dependency on claims 1, 30, 
and 45, respectively, neither Hershey, Chandra, nor Schwaller, either alone or in 
combination, teach or suggest the features of dependent claims 2, 8, 10, 13, 15, 18, 22, 
24, 27, 31, 37, 39, 42, 44, 46, 52, 54, 57, and 59. Accordingly, Applicants respectfully 
request withdrawal of the rejection of claims 2, 8, 1 0, 1 3, 1 5, 1 8, 22, 24, 27, 3 1 , 37, 39, 
42, 44, 46, 52, 54, 57, and 59 under 35 U.S.C. § 103(a). 

VII. Rejection under 35 U.S.C. 8 103(8) based on Hershev. Chandra. SchwaUer. 
and Wlaschin 

The Final OflFice Action rejects claims 60-64 under 35 U.S.C. § 103(a) as 
allegedly being unpatentable over Hershey, Chandra, Schwaller, and fiirther in view of 
Wlaschin et al. (U.S. Patent no. 6,163,775). This rejection is respectfiilly traversed. 

Claims 60-64 are dependent from respective ones of independent claims 1,30, 
and 45. The deficiencies of Hershey, Chandra, and Schwaller with regaird to claims 1, 30, 
and 45 have been discussed above. Wlaschin does not provide for these deficiencies. 
Wlaschin is cited as allegedly teaching using tables to report data. Wlaschin does not 
teach or suggest repK)rts that have entries for a plurality of transaction steps of a 
transaction in a script that is provided to local and/or remote probes, as recited in claims 
1, 30, and 45. Thus, even if Wlaschin were combinable with the other references, the 
addition of Wlaschin would not result in the features of the independent claims discussed 
above being taught or suggested. 

In addition to the above, neither Hershey, Chandra, Schwaller, nor Wlaschin, 
either alone or in combination, teach or suggest the specific features recited in claims 60- 
64. Nowhere in any of the references is there any teaching to output a report to a user, 
the output of the report comprising a table having at least one row for each execution of 
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the script and columns ordered according to £in order of transaction steps in the script. 
The Final Office Action alleges that Hershey teaches reporting results to a user, Chandra 
teaches a table report, and Wlaschin teaches a method and system of utilizing tables to 
report data. The Final Office Action alleges that the other differences between the 
claimed subject matter and the cited references is found only in "non-functional data 
stored on the article of manufacture" which does not distinguish the claimed invention 
from the prior art in terms of patentability. 

Applicants respectfully submit that the configuration of the output generated by 
the present invention as recited in claims 60-64 does impart functionality and thus, is not 
merely non-functional descriptive material as alleged by the Examiner. With the output 
generated in the manner set forth in claims 60-64, a clearly ordered series of transaction 
steps corresponding to the order in the script is displayed along with their corresponding 
performance information. From such an output, a user may follow the order of 
transaction steps to determine where in the chain of steps a problem or performance 
degradation may have occurred and may take appropriate action. If a user determines 
that the total time for the script to execute is unsatisfactory, the user may traverse each of 
the transaction steps in order to determine where the greatest degradation in performance 
is felt and what that affect may have been on later transaction steps further down in the 
chain of transaction steps. Thus, the configuration of the output as recited in claims 60- 
64 does impart functionality and is an important feature of the claimed invention as 
recited in claims 60-64 that is not taught or even suggested by the cited references 
because none of the cited references teach or even suggest the monitoring of performance 
on a transactional step basis. To the contrary, none of the tables or even displays of the 
cited references show any individual entries for transaction steps of a script, let alone £in 
ordered arrangement as set forth in claims 60-64. This is further evidence that the cited 
references do not, and are not capable of, generating a report that includes entries for 
each transaction step in a script. Thus, in addition to being dependent upon their 
respective independent claims, claims 60-64 recite additional features that are not taught 
or suggested by the alleged combination of references. 
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VIII. Conclusion 



It is respectfully urged that the subject application is in condition for allowance. 
The Examiner is invited to call the undersigned at the below-listed telephone number if in 
the opinion of the Examiner such a telephone conference would expedite or aid the 
prosecution and examination of this application. 



Respectfully submitted. 



DATE: July 27. 2010 
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Walder Intellectual Property Law, P.C. 
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